1. Field of the Invention
The present invention relates generally to an arrangement and method for treating interrupt requests from I/O (Input/Output) devices in a data processing system which operates in a virtual machine mode, and more specifically to such an arrangement and method by which an interrupt request from an I/O device to a guest OS (operating system) is effectively processed irrespective of an occurrences of the same kind of request to a host operating system.
2. Description of the Prior Art
As is known in the art, a virtual machine is an illusion of a real machine. It is created by a virtual machine monitor (viz., virtual machine operating system), which makes a single real machine appear to be several real machines. The virtual machine monitor, under control of a high-ranking operating system, is actually able to run multiple different operating systems at once, each of them on its own virtual machine. In other words, the virtual machine monitor can run multiple operating systems with each operating system running its own programs. Throughout the instant disclosure, the above-mentioned high-ranking operating system is referred to as a host operating system, while each of the multiple operating systems under control of the virtual machine monitor is referred to as a guest operating system.
Before turning to the present invention it is deemed preferable to describe a known technique with reference to FIGS. 1-2.
FIG. 1 shows in block diagram form a schematic arrangement of a computer which operates in a virtual machine mode. This figure will again be referred to when discussing the present invention. FIG. 2 is a block diagram showing details of two blocks of FIG. 1.
In FIG. 1, a main memory 10 stores a host operating system (OS) 12, a virtual machine (VM) monitor 14 which is regarded as a job supervised by the host OS 12, a plurality of guest operating systems 16a-16m which are controlled by the VM monitor 14 to operate as virtual machines independently of one another. The main memory 10 further memorizes a job 18 under direct control of the host OS 12, and a plurality of jobs 20a-20m which run respectively, independently under the control of the guest operating systems 16a-16m.
A CPU selector 22 is interposed between the host OS 12 and a plurality of CPUs 24a-24n. In this arrangement, it is assumed that the CPU 24a acts as a master CPU while the remainder (24b-24n) act as slave CPUs. On the other hand, a CPU selector 26 is arranged between the guest OS's and the plurality of CPUs 24a-24n. The virtual machine monitor 14 determines which of the CPUs 24a-24n are to be utilized for the guest OS's 16a-16m. Each of the CPU selectors 22, 26 is comprised of software and arranged within the main memory 10 as illustrated.
A plurality of I/O devices 28 are connected with the CPUs 24a-24n by way of an I/O device controller 30.
FIG. 2 shows details of the CPU 24a, which operates as a master CPU, and the I/O device controller 30. The CPU 24a includes an EPU (executing/processing unit) 32, a host OS I/O device access request generator 34, a guest OS I/O device access request generator 36, an AND gate 38 arranged in the illustrated manner. The host OS is able to access or operate the I/O devices by way of the host OS I/O device access generator 34 while each of the guest OS's is capable of accessing the I/O devices by way of the guest OS I/O access request generator 36.
The EPU 32 of the CPU 24a includes an EPU flag 44 which takes the form of a flip flop, and an interrupt information storage section 46 comprised of an interrupt I/O device register section 48 and an interrupt mask register section 50, and a interrupt activator 52.
In more specific terms, the register section 48 includes an interrupt I/O device register (FIG. 4(A)), while the register section 50 includes two registers: (a) a host interruption mask register and (b) a virtual interruption mask register, as shown in FIGS. 4(B) and 4(C).
The content of the EPU flag 44 is set to "1" (YES) or "0" (NO) under control of software. Each of the other CPUs 24b-24n which operate as slaves, is configured in the same manner as the master CPU 24a.
As will explained later, the interrupt activator 52 responds to the logic level of the AND gate 38 and uses the information set in the interrupt information storage section 46 to determine if an interrupt request applied thereto from the controller 30 is to be acceptable. It will be understood that the physical connections between the I/O devices and the interrupt I/O device register section 48 which allows the above mentioned determination are not shown for illustrative simplicity. The I/O device controller 30 includes an OS interrupt request generator 54.
The operations of the above described device will now be discussed with reference to FIGS. 3 and 4.
When a given I/O device completes an activity on behalf of the host OS 12, the I/O device controller 30 responds inducing the OS interrupt request generator 54 to output a logic 1 level signal to the AND gate 38. It has been assumed that the CPU 24a shown in FIG. 2 operates as a master CPU and hence the EPU flag 44 has been set to "1". Accordingly, the AND gate 38 opens and a logic 1 is applied to the interrupt activator 52. In response to this, the interrupt activator 52 checks the contents of the registers in the sections, 48 and 50.
As mentioned above, the register section 48 contains the interrupt I/O device register (referred to as IDR) (FIG. 4(A)), while the register section 50 contains the host and virtual interrupt mask registers (FIGS. 4(B)-4(C)). By way of example, the number of the I/O devices are 32 and accordingly the number of bits of each of the registers shown in FIGS. 4(A)-4(C) is also 32. In more detail, the 32 bits of each of the registers of FIGS. 4(A)-4(C) are respectively assigned to the 32 devices.
Assuming that I/O device #5 has just completed an activity, then the bit #5 of the IDR (FIG. 4(A)) is set to logic 1 by the operation of the I/O device controller 30. In the case that the host OS has utilized the #5 device, the fifth bit (#5) of the host interrupt mask register (referred to as H-IMR) (FIG. 4(B)) is set to "1" and the remaining bits of the register in question assume "0" as shown in FIG. 4(B). The bits of the virtual interrupt mask register (referred to as V-IMR) (FIG. 4(C)) are accordingly all "0" in this instance.
More specifically, at step 98 of the flow chart shown in FIG. 3, the interrupt activator 52 is supplied with the interrupt request. At step 100, the contents of the H-IMR (FIG. 4(B)) of the section 50 is readout and checked to determine if all the cells are "0" or not. In this instance, the check result is NO and hence the control goes to step 102 wherein the content of the IDR of the section 48 is read out and ANDed on a bit by bit basis with the content of the H-IMR (FIG. 4(B)).
If the result of the logical products are all "0" at step 102, the control goes to step 110 while on the other hand, the control goes to step 104 wherein the bit which has been set to "1" (in this example cell #5) of the IDR is reset to "0". After this the control goes to step 106 wherein the identity of the I/O device which has just completed its activity (viz., the identity of the reset bit) is established. Thereafter, the interruption request is given to the host OS 12 (in this case) in step 108.
In the case that the guest OS 16a has utilized #5 device then the fifth bit (#5) of the G-IMR (FIG. 4(C)) is set to "1" (not shown). In this instance, the bits of the H-IMR (FIG. 4(B)) are accordingly all "0" although not shown in FIG. 4(B). Therefore, the control goes to step 110 wherein the contents of the IDR (FIG. 4(A)) and the V-IMR are ANDed on a bit by bit basis.
In the event that the logical products are all "0" at step 110, the control goes step 118 while on the other hand, it proceeds to step 112 wherein the same operations as performed in step 104 take place. After this at step 114 the same operations as performed in step 106 are induced. Following this, the control provides the guest OS with the interrupt request at step 116.
Returning to FIGS. 1 and 2, as mentioned above, the EPU of each of the slave CPUs 24b-24n is such that the EPU flag is normally set to "0". However, by way of the example given that the guest OS 16a is obliged to use the slave CPU 24b for some reasons of time slots assignment, the slave CPU 24b is required to accept an interrupt request from a I/O device which has been used by the guest OS 16a. This means that the EPU flag of the CPU 24b must be set to "1" before the interrupt request can be received from the I/O device controller 30. On the other hand, the host OS 12 accesses many of the I/O devices and accordingly, there are many interrupt requests directed to the host OS 12. However, each of these interrupt requests is applied to all of the CPUs 24a-24n. Therefore, the aforesaid known technique has encountered the problem that it is undesirably necessary to repeat steps 100 and 110 for the CPU 24b in order to block the interrupt request to the host OS 12. This of course means that time is wasted until the interrupt request to a guest OS 16a is detected at the EPU of the slave CPU 24b in the above-mentioned example.